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TECHNICAL FIELD 

The present disclosure generally relates to processing multimedia data, and 
more particularly, to extracting metadata from DV formatted multimedia data. 

BACKGROUND 

DV is a digital video format used world-wide for digital video cameras. 
The DV format is an international standard that was created by a consortium of 
companies typically referred to as the DV consortium. DV, originally known as 
DVC (Digital Video Cassette), uses a metal evaporate tape to record very high 
quality digital video. The DV video specification, lEC 61834, specifies the 
content, format and recording method of data blocks forming helical records on the 
digital tape. It also describes the common specifications for cassettes, modulation 
method, magnetization and basic system data, for digital video cassette recording 
systems using 6.35 mm (1/4 inch) magnetic tape, and the electrical and mechanical 
characteristics of equipment which provides for the interchangeability of recorded 
. cassettes. 

DV video information is carried in a data stream at a rate of about 29 
megabits per second (3.7 MByte/sec). A DV video frame typically includes 10 
DIF sequences, each of which consists of 150 DIF blocks having 80 bytes of data 
each. In addition to video and audio data, each DV video frame includes extra 
data associated with the video and audio data called DV metadata. 

DV metadata can include a wide range of data associated with the video 
data in a DV frame. For example, DV metadata can include the time and date that 
video was recorded, various settings on the camcorder at the time the video was 
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recorded, and so on. According to lEC 61834-4, DV metadata is divided into 256 
separate "packs". Although 256 packs are reserved for DV metadata, many of the 
packs have yet to be defined. Each pack consists of 5 bytes. The first byte in each 
DV metadata pack is the pack ID, and the next four bytes consist of binary fields. 

The DV format permits each DV video frame to stand on its own without 
having to rely on any data fi-om preceding or following frames. For example, the 
same metadata is repeated numerous times within a DV frame. The redundancy 
built into each DV frame and the wealth of additional data (i.e., metadata) 
inherent to the DV format make DV video an ideal format for editing. However, 
various difficulties prevent current DV editing applications from taking full 
advantage of the unique features of DV video that make it ideally suited for 
editing. 

In a typical DV scenario, video is recorded and converted to digital form in 
a camcorder. The video data on the digital tape can be played in a digital tape 
drive, such as the one in the camcorder, in a DVCR, or in a standalone unit. DV 
data can be transferred electronically via firewire to a computer's hard disk. The 
transfer process is typically performed by a capture driver, a standalone utility, or a 
component of an editing application executing on a computer such as a desktop 
personal computer. During the transfer process, the DV data is "wrapped" into a 
file format commonly understood by computers, such as AVI for Windows or 
Quicktime for the Mac. Therefore, once the transfer process is finished, the DV 
data on the computer hard drive is wrapped in a file format that standard editing 
applications can process. Various editing applications, such as Adobe® 
Premiere® Pro, enable nonlinear video editing through real-time video and audio 
editing tools. 
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However, as indicated above, current DV editing applications take little or 
no advantage of the rich information provided in the DV video format that makes 
it ideally suited for editing. The main reason for this is that it is difficult to extract 
the DV metadata from within DV video frames. DV metadata extraction currently 
requires an application developer to write its own custom code for extracting 
specifically desired metadata. In addition, an extraction process implemented by a 
DV editing application would be very processor intensive, which would hinder the 
performance of other editing functions of the application. One consequence of 
these difficulties is that DV metadata is generally not exploited by most DV 
editing applications. , 

Accordingly, a need exists for a way to extract DV metadata from DV data 
streams. . 

SUMMARY 

Extraction of DV metadata from a DV data stream is described herein. 

In accordance with one implementation, an instruction is received 
specifying additional per-frame DV metadata to be extracted from a DV data 
stream. The metadata is extracted from DV frames of the DV data stream. 

In accordance with another implementation, metadata is stored in a 
container and the container is attached to a DV sample of a DV frame. The 
container is manageable to have additional DV metadata structures stored within it 
and to provide for the retrieval of metadata items that have been stored within it. 

In accordance with yet another implementation, a DV metadata structure is 
stored within the container. The DV metadata structure is an unpacked version of 
a DV metadata pack. The DV metadata structure includes binary values unpacked 
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from the DV metadata pack and a different variable name associated with each 
binary value. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The same reference numerals are used throughout the drawings to reference 
like components and features. 

Fig. 1 illustrates an exemplary environment suitable for DV . metadata 
extraction. 

Fig. 2 illustrates an exemplary embodiment of a computer suitable for 
extracting DV metadata from a DV data stream. 

Fig. 3 illustrates an example of DV data being processed through various 
processing components. 

Fig. 4 illustrates components of a DV metadata extraction tool: 

Fig. 5 illustrates a container having one or more DV metadata packs and 
one or more unpacked DVJVIETADATA structures. 

Fig. 6 illustrates a block diagram of an exemplary method for extracting DV 
metadata from a DV data stream. 

Fig. 7 illustrates a block diagram of another exemplary method for 
extracting D V metadata from a D V data stream. 

Fig. 8 illustrates an exemplary computing environment suitable for 
implementing a computer such as that in Fig. 2. 
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DETAILED DESCRIPTION 

Overview 

The following discussion is directed to a set of interfaces, data structures 
and events for representing a DV metadata extraction tool. The DV metadata 
extraction tool includes an API (application programming interface) for describing 
DV metadata packs that are to be extracted from a DV data stream. The extraction 
API is called IMFExtractDVMetadata, and it supports methods for specifying and 
removing DV metadata packs to be extracted from DV frames. The extraction API 
also supports methods for determining the number of DV metadata packs in an 
extraction list and determining the ID of a DV metadata pack at a given index in 
the extraction list. 

The DV metadata extraction tool also includes an API for describing a 
container that holds DV metadata once it has been extracted from a DV frame. 
The container API is called IMFDVMetadataContainer, and it supports methods 
for adding and removing DV structures to the container and for retrieving data 
from the container, removing data from the container, and iterating through the 
container. The DV metadata extraction tool also includes a collection of higher- 
level structures that represent unpacked DV metadata packs. 

The DV metadata extraction tool is generally described within the context 
of the Media Foundation architecture by Microsoft® Corporation. However, it is 
noted that the DV metadata extraction tool is designed and described herein in a 
manner that enables its use in any suitable multimedia architecture. 
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Exemplary Environment 

Fig. 1 illustrates an exemplary environment 100 that is suitable for DV 
metadata extraction. The exemplary environment 100 of Fig. 1 includes a 
computer 102 and one or more DV video input sources 104. 

DV video input sources 104 can be any type of device or communication 
network capable of transferring DV video content to computer 102, including for 
example, portable storage media 104(1) (e.g., magnetic discs, media cards, optical 
discs), a DV video recording device 104(2) (e.g., a digital camcorder), or a 
network 104(3) such as the Internet, a corporate network, or a home network. 

Video recording device 104(2) can be any of various digital recording 
devices capable of recording live-motion video and audio in DV format (i.e., on a 
digital tape) for later replay via a digital tape drive, for example, in a DVCR, a 
camcorder, or a personal computer such as computer 102. A video recording 
device 104(2) is typically capable of being connected directly to computer 102 
using an i.LINK (IEEE 1394) or Fire Wire digital interface, so that DV video 
content can be edited directly on the computer 102. 

Computer 102 may be implemented as various computing devices generally 
capable of receiving video content from various sources 104 and manipulating the 
video content for editing and playback through a resident multimedia architecture 
such as the Media Foundation architecture by Microsoft Corporation, for example. 
Computer 102 is otherwise typically capable of performing common computing 
functions, such as email, calendaring, task organization, word processing, Web 
browsing, and so on. In the described embodiments, computer 102 runs an open 
platform operating system, such as the Windows® brand operating systems from 
Microsoft®. Computer 102 may be implemented, for example, as a desktop 
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computer, a server computer, a laptop computer, or other form of personal 
computer (PC). One exemplary implementation of computer 102 is described in 
more detail below with reference to Fig. 8. 

As discussed in greater detail below with reference to the exemplary 
embodiments, computer 102 is generally configured with a multimedia architecture 
that includes a DV metadata extraction tool enabling the extraction of DV 
metadata from DV data. 

Exemplary Embodiments 

Fig. 2 illustrates an exemplary embodiment of a coniputer 102 suitable for 
extracting DV metadata from a DV data stream. A multimedia architecture and 
related components facilitating DV metadata extraction are described throughout 
this disclosure in the general context of computer/processor-executable 
instructions, such as program modules being executed by a personal computer. 
Generally, program modules include routines, programs, objects, components, data 
stmctures, etc., that perform particular tasks or implement particular abstract data 
types. Moreover, those skilled in the art will appreciate that such program 
modules may be implemented using other computer system configurations, 
including hand-held devices, multi-processor systems, microprocessor based or 
programmable consumer electronics, network PCs, minicomputers, mainframe 
computers, and the like. Furthermore, such program modules may also be 
practiced in distributed computing environments where tasks are performed by 
remote processing devices that are linked through a communications network. In a 
distributed computing environment, program modules may be located in both local 
and remote memory storage devices. In the current computing environment of Fig. 
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2, computer 102 is generally illustrated as having program modules located in a 
local memory (not shown). As indicated above, an exemplary implementation of 
computer 102 is described in greater detail below with reference to Fig. 8. 

The DV metadata extraction tool 200 shown in Fig. 2 may operate in the 
context of a multimedia architecture 202 such as Microsoft's Media Foundation. 
However, the DV metadata extraction tool 200 is not limited to operation in such 
an architecture 202. Thus, the DV metadata extraction tool 200 might also be 
implemented, for example, as a stand alone component or a subcomponent of 
another application program. Prior to describing the DV metadata extraction tool 
200, a brief description of the multimedia architecture 202 will be provided with 
reference to Fig. 2. 

As shown in Fig. 2, multimedia architecture 202 includes various 
component layers: In addition, multimedia architecture 202 also generally includes 
supporting or associated media applications 204. Such applications 204 are 
illustrated in Fig. 2 separately from the multimedia architecture 202, but might also 
be shown as a part of the architecture 202. The component layers of multimedia 
architecture 202 include control component layer 206, core component layer 208, 
base component layer 210, development platform layer 212 and definition layer 
214. 

Components of control component layer 208 include media processor 234, 
basic editor 218, basic encoder 220, media session 222, topology loader 224, 
media engine 226, and source resolver 228. These components generally make up 
task oriented APFs (application programming interfaces) that may be fiilly 
managed or un-managed. The control components 206 generally provide 
management fiinctions that perform tasks such as linking together appropriate core 
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layer components 208 for processing media. For example, the topology loader 224 
checks the multimedia data type of an incoming media file and determines which 
processing components (i.e., 230, 232, 234, 236, 238) of the core layer components 
208 need to be linked into a processing chain in order to properly render the data 
typei Note that for purposes of this disclosure, the media data type is DV data. A 
media engine component 226 of the control layer 206 manages the processing of 
the data through the chain of processing components (i.e., 230, 232, 234, 236, 238) 
assembled by the topology loader 224. For example, the media engine 226 pushes 
the data through the processing chain, controlling when to stop playback, start 
playback^ play backwards, jump to a particular time, and so on. 

Core layer components 208 include media sources 230, metadata read/write 
232, MUX/Dmux 234, transforms 236, and media sinks 238. Media sources 230 
provide multimedia data through a generic, well-defined interface. The media 
sources 230 describe the presentation, including video data streams to be accessed. 
There are many implementations of media sources for providing multimedia data 
fi-om different multimedia file types or devices. However, the present disclosure is 
directed to multimedia in a DV format. 

The transforms 236 of core layer 208 each perform some type of 
transformation operation on multimedia data through a generic, well-defined 
interface. Transform examples include codecs, DSPs, video resizers, audio 
resamplers, statistical processors, color resamplers, and others. Although the 
MUX/Dmux 234 (Dmux 234, hereinafter) is illustrated separately within core layer 
208, it is one representation of a transform 236 that takes interleaved multimedia 
data as an input, and separates the data into individually useful media streams of 
multimedia data. Thus, in the context of this disclosure, the Dmux 234 is a DV 
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Dmux 234 that, among other things, spHts out the video and audio components of 
DV frames or samples from a DV media source 230. 

The Dmux 234 is also illustrated within the multimedia architecture 202 of 
Fig. 2 as including DV metadata extraction tool 200. As described in further detail 
herein below, Dmux 234 supports DV metadata extraction through the DV 
metadata extraction tool 200. The DV metadata extraction tool 200 generally 
allows the user to create and manage an extraction list of DV Metadata packs to be 
extracted from a DV data stream. Once a DV metadata pack ID is added to the 
extraction list, the DV Dmux 234 extracts the associated DV metadata pack from 
each DV frame as it splits out the video and audio components of the DV frame. 
The DV Dmux 234 stores the DV metadata pack in a container and attaches the 
container to the outgoing video sample as an extended attribute. Although the DV 
metadata extraction tool 200 is discussed herein in conjunction with, or as a part 
of, Dmux 234, this is not intended as a limitation as to where the DV metadata 
extraction tool 200 can be implemented within the core layer 208 or elsewhere. 
Implementing the DV metadata extraction tool 200 within the Dmux 234 is a 
preferred embodiment because of the benefits of efficiency provided by the 
splitting function of the Dmux 234. Thus, the DV metadata extraction tool 200 
may just as easily be part of the media source 230, a DM0 (DirectX Media 
Object), or a stand-alone software component anywhere else that has access to the 
DV data stream. The DV metadata extraction process is discussed in greater detail 
below with reference to subsequent figures. 

Media sinks (sinks) 238 are also included in the core layer 208 processing 
components. Sinks 238 generally accept multimedia data as input through a 
generic, well-defined interface. There are many implementations of media sinks 
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for performing different functions with multimedia data, such as writing 
multimedia data to a given file type or to a network, or displaying the multimedia 
data on a video monitor using a video card. 

The base components 210 and development platform 212 of multimedia 
architecture 202 generally make up mostly un-managed APFs. The base 
components 210 include media container 240, networking 242, DRM 244, MPEG 
format support 246, and audio/video engine 248. These components generally 
perform individual functions in support of multimedia architecture 202. The 
development platform 212 generally includes resource management infrastructure 
and common primitive types such as samples, clocks, events, buffers, and so on. 
The definitions layer of multimedia architecture 202 includes definitions and 
policies related to schemas, protocols, and formats (e.g., metadata, device models, 
types, etc.). - 

Fig. 3 illustrates an example of DV data being processed through various 
processing components of the core layer 208, including the DV metadata 
extraction tool 200 of Dmux 234, as briefly discussed above. DV data samples 
(DV frames) 300 enter the Dmux 234 where they are split into video samples 302 
and audio samples 304. The video samples 302 proceed through the processing 
chain to various processing components such as video codec 308 and video 
renderer 310, after which they might be displayed on a video, display 312. The 
audio samples 304 proceed through the processing chain to various processing 
components such as audio renderer 314, after which they might be played through 
an audio speaker 316. While the Dmux 234 is splitting out the DV samples 300, it 
also extracts DV metadata packs that it locates within the DV samples 300 in 
accordance with DV metadata pack IDs (DVPacklDs) from an extraction list (see 
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Fig. 4). Upon locating a DV metadata pack whose DVPackID is in the extraction 
list, the Dmux 234 extracts the DV metadata jpack and stores it in a container 306 
and attaches the container 306 to the corresponding outgoing video sample 302 as 
an extended attribute. 

For a certain subset of DV metadata packs, the DV metadata extraction tool 
200 also provides extended support of DV pack-specific data structures, called 
DV__METADATA structures (see Fig. 5). In addition to storing the DV metadata^ 
packs in the container 306 for these extended support packs, the Dmux 234 also 
stores the unpacked DV_METADATA structures in the container 306. Thus, for 
certain extended support DV metadata packs, the DV metadata extraction tool 200 
breaks down the packed data into usable DV pack-specific data structures, or 
DV_METADATA structures. Fig.. 5 illustrates a container 306 having one or 
more DV metadata packs 500 and one or more unpacked DV METADATA 
structures 502 that correspond with the DV metadata packs 500. 

According to lEC 61834-4, there are 256 DV metadata packs in the DV 
format. The 256 DV metadata packs are shown herein below in a reference 
section of this disclosure entitled Interface Definition Language . Although 256 
packs are reserved for DV metadata, many of the packs have yet to be defined. 
The binary pack layout for various DV metadata packs is shown in the Interface 
Definition Language reference section. The DV metadata pack binary layouts 
included are for those DV metadata packs that are specifically supported as 
unpacked DV pack-specific data structures (i.e., DV_METADATA structures). 
Thus, the Interface Definition Language section also includes the unpacked 
DVv_METADATA structures for the specifically supported DV metadata packs. In 
general, each DV metadata pack consists of 5 bytes in its binary layout. The first 
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byte in each DV metadata pack is the DVPackID, and the next four bytes consist 
of binary fields. 

Referring again to Figs. 3 and 4, the DV metadata extraction tool 200 
supports an extraction API 400 (application programming interface) that maintains 
the extraction list 404 through various methods. The DV metadata extraction tool 
200 also supports a container API 402 that will be discussed below. Fig. 4 
illustrates the DV metadata extraction tool 200 along with the extraction API 400 
and container API 402 it supports. Also shown in Fig. 4 is the extraction list 404, 
which may contain various DVPacklDs. The extraction API 400 is called the 
IMFExtractDVMetadata API, and the methods it supports include AddPack, 
RemovePack, RemoveAUPacks, GetCount, and GetPack. 

The AddPack method adds the specified pack to the extraction list 404 of 
DV Packs to be extracted on each DV firame 300 according to the following 
syntax: 

HRESULT AddPack( 
BYTE DVPackID 

); 

DVPackID is an input parameter that specifies the PackID for a DV 
metadata pack. This is a member of the DVPACKID enum. In a resulting 
DV_METADATA structure the PackID is in DvMetadata.Pack[0]. The only pack 
that cannot be added to the extraction list 404 is DVPAC_NO_INFO (OxFF) (see 
the Interface Definition Language section). 

If the AddPack method . succeeds, it retums S_OK. However, an 
E_INVALIDARG will be retumed if the DVPackID is DVPACK_NO_.INFO. 
Other errors may also be retumed. 
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A call to AddPack from an editing application 204, for example, adds a 
DVPackID to the extraction list 404. The function will succeed even if the pack 
(i.e., the DVPackID) has previously been added. The packs are not reference 
counted so a pack needs only to be removed once even if it has been added twice. 

The RemovePack method removes the specified pack from the extraction 
list 404 of packs to be extracted on each DV frame 300 according to the following 
syntax: 

HRESULT RemovePack( 
BYTE DVPackID 

); 

DVPackID is an input parameter that specifies the PackID for a DV 
metadata pack. This is a member of the DVPACKID enum. In a resulting 
DV_METADATA structure, the PackID is in DvMetadata.Pack[0]. 

If the RemovePack method succeeds, it retums S_OK. If the pack is not in 
the extraction list 404 then the fimction retums E_ITEM_NOT_FOUND. Other 
error codes may also be retumed. 

A call to RemovePack from an editing application 204, for example, 
removes the specified pack from the extraction list 404. 

The RemoveAUPacks method clears the extraction list 404 of DV Packs 
that the Dmux 234 would extract according to the following syntax: 

HRESULT RemoveAUPacksQ; 

There are no parameters input with the RemoveAUPack method. If the 
method succeeds, it retums S_OK. Other error codes may also be retumed. 
Calling RemoveAUPack, by an editing, application 204, for example, clears the 
entire extraction list 404. 
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The GetCount method returns the number of DV packs that are in the 
extraction list 404 according to the following syntax: 

HRESULT GetCount( 
DWORD* pCount 

); 

The pCount parameter is an output parameter that specifies the number of 
packs in the extraction hst 404. If the method succeeds, it retums S_OK. CalHng 
GetCount retrieves the number of items (i.e., DVPacklD's) in the extraction Hst 
404. 

The GetPackID method retums the DVPackID of a pack at a given index in 
the extraction list 404 according to the following syntax: 

HRESULT GetPack( 
DWORD Index, 
BYTE* pDVPackID 

); 

The Index parameter is an input parameter that is the index in the extraction 
list 404 of the desired DVPack ID. The pDVPackID is an output parameter that 
is a pointer to a byte where the object will copy the DVPack ID of the item found 
at the specified index. 

If the GetPackID method succeeds, it retums S_OK. If the Index is out of 
range, the method retums the error code, MF E INVALIDINDEX. If an error is 
returned the value OF pDVPackID is DVPACK_^NO_INFO (OxFF). 

The GetPackID method allows the caller (e.g., application 204) to retrieve 
the fiill list of items to be extracted by repeatedly calling GetPackId and 
incrementing the index until E_INVALIDARG is retumed. 
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As mentioned above, the DV metadata extraction tool 200 also supports a 
container API 402 (see Fig. 4). The container 306 (Fig. 3) is placed as a sample 
attribute on the video sample 302 that is split out by the Dmux 234. The container 
API 400 is called the IMFDVMetadataContainer API, and the methods it supports 
include Add, Remove, RemoveAU, GetCount, Lock, Unlock, GetFirst and 
GetNext. In general, the IMFDVMetadataContainer API provides a general 
mechanism for adding attributes to the list, removing attributes from the list, 
clearing the container 306 and iterating through the container 306. 

The Add method adds a DV pack-specific data structure, or 
DV^METADATA structure, to the container 306 according to the following 
syntax: 

HRESULTAdd( 
const DV_METADATA* pMetadata, 
UINT32* pulndex 

); 

The pMetadata parameter is an input parameter that is a constant pointer to 
a DV_METADATA structure. pMetadata->cbSize is used to allocate memory in 
the container 306 and a copy of the entire DV_METADATA structure placed in 
the newly allocated memory. 

The ullndex is an output parameter that retums the index of the newly 
added DV_METADATA structure. The index may change if additional structures 
are added or deleted from the container 306. 

If the Add method succeeds, it retums S_OK. It may also retum 
E_OUTOFMEMORY if it is unable to allocate sufficient space for the new item. 
This operation will complete in constant time 0(k). This operation will block until 
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the lock is released if the container has been locked by another thread, (see Lock 
and Unlock methods below). 

The Remove method removes a DV pack-specific data structure, or 
DV METADATA structure, from the container 306 according to the following 
syntax: 

HRESULT Remove( 
UINT32 ulndex 

The ulndex parameter is an input parameter that indicates the index of the 
item that is to be removed from the container 306. When an item is removed from 
the container 306 the index of items that remains in the container 306 may change. 

If the method succeeds, it returns S_OK. It may also return 
E_INVALIDARG if an item with a matching index cannot be found. This 
includes the case when the container 306 is empty. This operation will complete in 
linear time 0(n), where n is the number of items stored in the list. This operation 
will block until the lock is released if the container has been locked by another 
thread, (see Lock and Unlock methods below). 

The RemoveAll method clears all items (e.g., DV metadata packs and DV 
pack-specific data structures) from the container 306 according to the following 
syntax: 

HRESULT RemoveAll( ); 

There are no parameters input with the RemoveAll method. If the method 
succeeds, it retums S_OK and there will be no more items in the container 306. 
However, it does not necessarily follow that the memory will be freed. The 
container 306 may implement a pooling scheme to avoid repeated small 
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allocations. This operation will complete in linear time 0(n), where n is the 
number of items in the container 306. This operation will block until the lock is 
released if the lock has been acquired on another thread, (see Lock and Unlock 
methods below). 

The GetCount method retums the count of items in the container 306 
according to the following syntax: 

HRESULT GetGount( 
UINT32* puCount 

); 

The puCount parameter is an output parameter that retums number of items 
currently in the container 306. If the method succeeds, it retums S_OK. 

This operation will complete in constant time 0(k). The count returned is 
only valid at the time that the call was made. Objects may be added or removed by 
other threads. Locking the object will prevent other threads from adding or 
removing items from the container until the lock is released, (see Lock and 
Unlock methods below). 

The Lock method is used to lock the container 306 for exclusive access. 
This guarantees that the container 306 can be iterated and the returned pointers to 
DV_METAD ATA structures will remain valid as long as the lock owner does not 
add or remove items. The syntax for this method is as follows: 

HRESULT LockO; 

There are no input parameters with the Lock method. If the method 
succeeds, it retums S_OK. It may return other error codes. If the Lock is 
unavailable, the call will block until the lock can be acquired. 
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The Unlock method releases the lock obtained via the Lock method 
according to the following syntax. 

HRESULT UnlockO 
UINT32* pulndex, 

const DV^METADATA** pMetadata 

); 

There are no input parameters with the Unlock method. If the method 
succeeds, it returns S_OK. It may return other error codes. 

The GetFirst method starts iterating from the beginning of the container 306 
according to the following syntax: 

HRESULT GetFirst( 
UINT32* pulndex, 

Const DV_METADATA** ppMetadata 

); 

The pulndex parameter is an output parameter that specifies the index of 
the item retrieved from the container 306. The ppMetadata parameter is an 
output parameter that specifies a pointer to the objects intemal data structure 
containing the metadata. This pointer may be invalidated if items are added or 
removed from the container 306. 

If the method succeeds, it retums S OK. The method may return 
E_INVALIDARG if the index is out of range or the container 306 has had an item 
added or removed from it since the last call to GetFirstQ. The method will return 
MF_E_INVALIDREQUEST if the object has not been locked. Calling the Lock 
method ensures that items are not added or removed fi"om the container 306 by 
other threads while iterating the list. 

The GetNext method iterates through each item in the container 306 
according to the syntax: 
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HRESULT GetNext( 
UINT32* pulndex, 

Const DV^METADATA** ppMetadata 

); 

The pulndex parameter is an output parameter that specifies the index of 
the item retrieved from the container 306. The ppMetadata parameter is an output 
parameter that specifies a pointer to the objects internal data structure containing 
the metadata. This pointer may be invahdated if items are added or removed from 
the container 306. 

If the method succeeds, it returns S_OK. The method may retum 
E_INVALIDARG if the index is out of range or the container 306 has had an item 
added or removed from it since the last call to GetFirstQ. The method will retum 
MF__E_INVALIDREQUEST if the object has not been locked. Calling the Lock 
method ensures that items are not added or removed from the container 306 by 
other threads while iterating the list. 

Exemplary Methods 

Example methods for extracting DV metadata from a DV data stream will 
now be described with primary reference to the flow diagrams of Figs. 6-7. The 
methods apply generally to the exemplary embodiments discussed above with 
respect to Figs. 2 - 5. The elements of the described methods may be performed by 
any appropriate means including, for example, by hardware logic blocks on an 
ASIC or by the execution of processor-readable instructions defined on a 
processor-readable medium. 

A "processor-readable medium," as used herein, can be any means that can 
contain, store, communicate, propagate, or transport instructions for use by or 
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execution by a processor. A processor-readable medium can be, without 
limitation, an electronic, magnetic, optical, electromagnetic, infrared, or 
semiconductor system, apparatus, device, or propagation medium. More specific 
examples of a processor-readable medium include, among others, an electrical 
connection (electronic) having one or more wires, a portable computer diskette 
(magnetic), a random access memory (RAM) (magnetic), a read-only memory 
(ROM) (magnetic), an erasable programmable-read-only memory (EPROM or 
Flash memory), an optical fiber (optical), a rewritable compact disc (CD-RW) 
(optical), and a portable compact disc read-only memory (CDROM) (optical). 

Fig. 6 shows an exemplary method 600 for extracting DV metadata from a 
DV data stream. At block 602, an instruction is received that specifies additional 
per-frame DV metadata to extract from a DV data stream. The instruction is 
received by a DV metadata extraction tool 200 that can be part of a multimedia 
architecture 202 on a computer 102. The instruction is typically received from an 
application 204, such as a DV editing application executing on computer 102. The 
instruction is directed to an extraction interface 400 of the DV metadata extraction 
tool 200 in the form of a method call supported by the extraction interface 400. 
The instruction identifies the DV metadata by a DVPackID included within the 
method call. Method calls supported by the extraction interface 400 include an 
AddPack method call to add a DVPackID to a DV metadata extraction list 404, a 
RemovePack method call to remove a DVPackID from the extraction list 404, and 
a RemoveAUPacks method call to remove all DVPacklDs from the extraction list 
404. Additional method calls supported by the extraction interface 400 include a 
GetCount method call that returns a number indicating an amount of DVPacklDs 
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present in the extraction list 404 and a GetPackID method call that returns a 
DVPackID at a specified index in the extraction list 404. 

At block 604, the DV metadata specified in the instruction is extracted from 
a DV frame of the DV data stream. In one implementation, a Dmux 234 within a 
core layer 208 of the multimedia architecture 202 extracts the specified DV 
metadata as it splits the DV frame 300 into component video 302 and audio 304 
samples. The extraction includes the Dmux 234 looking at the DV metadata 
extraction list 404 to determine which DV metadata- packs to extract. At block 
606, the DV metadata is stored in a container 306. At block 608, the container is 
attached to a video sample 302 split off of the DV frame 300 by the Dmux 234. 

At block 610, the container is managed by the DV metadata extraction tool 
200. The DV metadata extraction tool 200 includes a container interface 402 that 
supports methods by which applications 204 can access and manage data in the 
container 306. Method calls supported by the container interface 402 are an Add 
method call that adds a DV_METADATA structure to the container, a Remove 
method call that removes a DV_METADATA structure firom the container, a 
RemoveAll method call that removes all items from the container, a GetCoimt 
method call that returns a number indicating an amount of items present in the 
container, a Lock method call that locks the container for exclusive access, an 
Unlock method call that unlocks the container, a GetFirst method call that retrieves 
an item from the container at a beginning index of the container, and a GetNext 
method call that retrieves an item from the container at a next index of the 
container. 

Fig. 7 shows another exemplary method 700 for extracting DV metadata 
from a DV data stream. At block 702, a DV metadata extraction list 404 is 
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managed. The extraction list 404 is managed by a DV metadata extraction tool 
200. The DV metadata extraction tool 200 supports an extraction interface 400 for 
managing the extraction list through various methods. Methods supported by the 
extraction interface 400 include an AddPack method call to add a DVPackID to a 
DV metadata extraction list 404, a RemovePack method call to remove a 
DVPackID from the extraction list 404, and a RemoveAllPacks method call to 
remove all DVPacklDs from the extraction list 404. Additional methods supported 
by the extraction interface 400 include a GetCount method call that returns a 
number indicating an amount of DVPacklDs present in the extraction list 404 and 
a GetPackID method call that retums a DVPackID at a specified index in the 
extraction list 404. 

At block 704, a DV metadata pack is extracted from a DV frame 300 based 
on a DVPackID in the extraction list 404. In one implementation, a Dmux 234 
within a core layer 208 of the multimedia architecture 202 extracts the specified 
DV metadata pack as it splits the DV frame 300 into component video 302 and 
audio 304 samples. The extraction includes the Dmux 234 looking at the DV 
metadata extraction list 404 to determine which DV metadata packs to extract. At 
block 706, the DV metadata pack is stored in an IMFDVMetadataContainer 306. 

At block 708, the DV metadata pack is unpacked into a DV pack-specific 
data structure. The DV pack-specific data structure breaks out the packed binary 
data from the DV metadata pack and assigns binary values to corresponding 
variable names, making it easy for an appUcation program 204 to utilize the data 
from the DV metadata pack. At block 710, the DV pack-specific data structure is 
stored in the IMFDVMetadataContainer 306, and at block 712, the 
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IMFDVMetadataContainer 306 is attached to a DV video sample 302 split off of 
the DV frame 300 by the Dmux 234. 

At block 714, the IMFDVMetadataContainer 306 is managed by the DV 
metadata extraction tool 200. The DV metadata extraction tool 200 includes a 
container interface 402 that supports methods by which applications 204 can 
access and manage data in the container 306. Method calls supported by the 
container interface 402 are an Add method call that adds a DV pack-specific data 
structure (called a DV_METADATA structure) to the container, a Remove method 
call that removes a DV METADATA structure from the container, a RemoveAU 
method call, that removes all items from the container, a GetCount method call that 
returns a number indicating an amount of items present in the container, a Lock 
method call that locks the container for exclusive access, an Unlock method call 
that unlocks the container, a GetFirst method call that retrieves an item from the 
container at a beginning index of the container, and a GetNext method call that 
retrieves an item from the container at a next index of the container. 

- While one or more methods have been disclosed by means of flow diagrams 
and text associated with the blocks of the flow diagrams, it is to be understood that 
the blocks do not necessarily have to be performed in the order in which they were 
presented, and that an altemative order may result in similar advantages. 
Furthermore, the methods are not exclusive and can be performed alone or in 
combination with one another. 
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Exemplary Computer 

Fig. 8 illustrates an exemplary computing environment 800 suitable for 
implementing a computer 102. Although one specific configuration is shown, 
client computer 102 may be implemented in other computing configurations. 

The computing environment 800 includes a general-purpose computing 
system in the form of a computer 802. The components of computer 802 can 
include, but are not limited to, one or more processors or processing units 804, a 
system memory 806, and a system bus 808 that couples various system 
components including the processor 804 to the system memory 806. 

The system bus 808 represents one or more of any of several types of bus 
stmctures, including a memory bus or memory controller, a peripheral bus, an 
accelerated graphics port, and a processor or local bus using any of a variety of bus 
architectures. An example of a system bus 808 would be a Peripheral Component 
Interconnects (PCI) bus, also known as a Mezzanine bus. 

Computer 802 typically includes a variety of computer readable media. 
Such media can be any available media that is accessible by computer 802 and 
includes both volatile and non-volatile media, removable and non-removable 
media. The system memory 806 includes computer readable media in the form of 
volatile memory, such as random access memory (RAM) 810, and/or non- volatile 
memory, such as read only memory (ROM) 812. A basic input/output system 
(BIOS) 814, containing the basic routines that help to transfer information between 
elements within computer 802, such as during start-up, is stored in ROM 812. 
RAM 810 typically contains data and/or program modules that are immediately 
accessible to and/or presently operated on by the processing unit 804. 
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Computer 802 can also include other removable/non-removable, 
volatile/non-volatile computer storage media. By way of example. Fig. 8 
illustrates a hard disk drive 816 for reading from and writing to a non-removable, 
non- volatile magnetic media (not shown), a magnetic disk drive 818 for reading 
from and writing to a removable, non-volatile magnetic disk 820 (e.g., a "floppy 
disk"), and an optical disk drive 822 for reading from and/or writing to a 
removable, non- volatile optical disk 824 such as a CD-ROM, DVD-ROM, or other 
optical media. The hard disk drive 816, magnetic disk drive 818, and optical disk 
drive 822 are each connected to the system bus 808 by one or more data media 
interfaces 826. Alternatively, the hard disk drive 816, magnetic disk drive 818, and 
optical disk drive 822 can be connected to the system bus 808 by a SCSI interface 
(not shown). 

The disk drives and their associated computer-readable media provide non- 
volatile storage of computer readable instructions, data structures, program 
modules, and other data for computer 802. Although the example illustrates a hard 
disk 816, a removable magnetic disk 820, and a removable optical disk 824, it is to 
be appreciated that otiier types of computer readable media which can store data 
that is accessible by a computer, such as magnetic cassettes or other magnetic 
storage devices, flash memory cards, CD-ROM, digital versatile disks (DVD) or 
other optical storage, random access memories (RAM), read only memories 
(ROM), electrically erasable progranmiable read-only memory (EEPROM), and 
the like, can also be utilized to implement the exemplary computing system and 
environment. 

Any number of program modules can be stored on the hard disk 816, 
magnetic disk 820, optical disk 824, ROM 812, and/or RAM 810, including by 
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way of example, an operating system, 826, one or more application programs 828, 
other program modules 830, and program data 832. Each of such operating system 
826, one or more application programs 828, other program modules 830, and 
program data 832 (or some combination thereof) may include an embodiment of a 
caching scheme for user network access information. 

Computer 802 can include a variety of computer/processor readable media 
identified as communication media. Communication media typically embodies 
computer readable instructions, data structures, program modules, or otfier data in 
a modulated data signal such as a carrier wave or other transport mechanism and 
includes any information delivery media. The term "modulated data signal" means 
a signal that has one or more of its characteristics set or changed in such a manner 
as to encode information in the signal. By way of example, and not limitation, 
conmiunication media includes wired media such as a wired network or direct- 
wired connection, and wireless media such as acoustic, RF, infrared, and other 
wireless media. Combinations of any of the above are also included within the 
scope of computer readable media. 

A user can enter commands and information into computer system 802 via 
input devices such as a keyboard 834 and a pointing device 836 (e.g., a "mouse"). 
Other input devices 838 (not shown specifically) may include a microphone, 
joystick, game pad, satellite dish, serial port, scanner, and/or the like. These and 
other input devices are connected to the processing unit 804 via input/output 
interfaces 840 that are coupled to the system bus 808, but may be connected by 
other interface and bus structures, such as a parallel port, game port, or a universal 
serial bus (USB). 
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A monitor 842 or other type of display device can also be conniected to the 
system bus 808 via an interface, such as a video adapter 844, In addition to the 
monitor 842, other output peripheral devices can include components such as 
speakers (not shown) and a printer 846 which can be connected to computer 802 
via the input/output interfaces 840. 

Computer 802 can operate in a networked environment using logical 
connections to one or more remote computers, such as a remote computing device 
848. By way of example, the remote computing device 848 can be a personal 
computer, portable computer, ia server, a router, a network computer, a peer device 
or other common network node, and the like. The remote computing device 848 is 
illustrated as a portable computer that can include many or all of the elements and 
features described herein relative to computer system 802. 

Logical connections between computer 802 and the remote' computer 848 
are depicted as a local area network (LAN) 850 and a general wide area network 
(WAN) 852. Such networking environments are commonplace in offices, 
enterprise-wide computer networks, intranets, and the Internet. When 
implemented in a LAN networking environment, the computer 802 is connected to 
a local network 850 via a network interface or adapter 854. When implemented in 
a WAN networking environment, the computer 802 typically includes a modem 
856 or other means for establishing communications over the wide network 852. 
The modem 856, which can be intemal or extemal to computer 802, can be 
connected to the system bus 808 via the input/output interfaces 840 or other 
appropriate mechanisms. It is to be appreciated that the illustrated network 
connections are exemplary and that other means of establishing communication 
link(s) between the computers 802 and 848 can be employed. 
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In a networked environment, such as that illustrated with computing 
environment 800, program modules depicted relative to the computer 802, or 
portions thereof, may be stored in a remote memory storage device. By way of 
example, remote application programs 858 reside on a memory device of remote 
computer 848. For purposes of illustration, application programs and other 
executable program components, such as the operating system, are illustrated 
herein as discrete blocks, although it is recognized that such programs , and 
components reside at various times in different storage coniponents of the 
computer system 802, and are executed by the data processor(s) of the computer. 

Interface Definition Language 

As indicated above, this IDL (Interface Definition Language) section lists 
the 256 DV metadata packs as well as the binary pack layout for various of those 
packs specifically supported in an extended manner as DV pack-specific data 
structures (i.e., DV METADATA structures) by the DV metadata extraction tool 
200. This section also includes the specific layouts of the unpacked DV metadata 
packs for the supported DV_METADATA structures. The DV metadata packs 
that have extended support are identified in the following table: 



TABLE 1 



CONTROL 








CASSETTE ID 


0X00 




TAPE LENGTH 


0x01 




TEXT HEADER 


0x08 




TEXT 


0x09 




TAG 


OxOB 








TITLE 








TIME CODE 


0x13 




BINARY GROUP 


0x14 




TEXT HEADER 


0x18 
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TEXT 


0x19 








PROGRAM 








PROGRAM REC 

X XWi</X_JXx^ XJLTX XX_I_/V_</ 

DTIME 


0x42 








AAUX 








SOURCE 


0x50 




SOURCE 
CONTROL 


0x51 




REC DATE 


0x52 




REC TIME 


0x53 




BINARY GROUP 

.K^JLM ^ X ]kX^ X ^^X^^^ X 


0x54 




CLOSED CAPTION 


0x55 




TR 


0x56 








VAUX 








SOURCE 


0x60 




SOURCE 
CONTROL 


0x61 




REC DATE 


0x62 




REC TIME 


0x63 




BINARY GROUP 


0x64 




CLOSED CAPTION 


0x65 




TR 


0x66 








CAMERA 








CONSUMER 
CAMERA 1 


0x70 




CONSUMER 

>_/ \^ X ^ KJ \_/ XTXX^XX. 

CAMERA 2 


0x71 




CAMERA 
SHUTTER 


0x7F 









Each DV pack-specific data structure (i.e., DV_METADATA structure) 
that has extended support by the DV metadata extraction tool 200 starts with a size 
and a DV Pack. The size member contains the size of the complete 
DV_METADATA structure. The DVPack (5 byte array) is the raw DV metadata. 
Each pack consists of 5 bytes. The first byte is the pack ID from Table 1 above. 
The next four bytes contain bit-fields containing the data. Each of the extended 
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support packs has an associated structure where the bit-fields are unpacked and 
lightly processed into a more useable form. The fiill definition of the DV Packs is 
found in lEC 61834-4. 

The 256 DV metadata packs and DV pack-specific data structures (i.e., 
DV_METADATA structures) supported by the DV metadata extraction tool 200 
are as follows: 



typedef enum _DVPACKID 

{ 



DVPACK^ 


_CONTROL_CASSETTE_ID = 


0x00, 


DVPACK^ 


^CONTROL_TAPE_LENGTH = 


0x01, 


DVPACK_ 


^CONTROL_TIMER__ACT_DATE = 


0x02, 


DVPACK^ 


^CONTROL_TIMER_ACS_S_S = 


0x03, 


DVPACK_ 


_CONTROL_PR_START_POINT_04 =. 


0x04, 


DVPACK_ 


_CONTROL_PR_START_POINT_05 .= 


0x05, 


DVPACK_ 


_C0NTR0L_TAG_ID_N0_GENRE = 


0x06, 


DVPACK_ 


_CONTROL_TOPIC_PAGE_HEADER *= 


0x07, 


DVPACK_ 


_CONTROL_TEXT_HEADER = 


0x08, 


DVPACK_ 


_C0NTR0L_TEXT = 


0x09, 


DVPACK. 


_CONTROL_TAG_0A = 


0x0 A, 


DVPACK_ 


CONTROL_TAG_0B = 


OxOB, 


DVPACK_ 


_CONTROL_TELETEXT_INFO = 


OxOC, 


DVPACK_ 


_C0NTR0L_KEY = 


OxOD, 


DVPACK_ 


_CONTROL_ZONE_END_0E = 


OxOE, 


DVPACK_ 


_CONTROL_ZONE_END_0F = 


0x0 P, 


DVPACK_ 


_TITLE_TOTAL_TIME = 


0x10, 


DVPAGK^ 


_TITLE_REMAIN_TIME = 


0x11, 


DVPACK_ 


_TITLE_CHAPTER_TOTAL_NO = 


0x12, 


DVPACK^ 


_TITLE_TIME_CODE = 


0x13, 


DVPACK_^ 


^TITLE_BINARY_GROUP = 


0x14, 


DVPACK_ 


_TITLE_CASSETTE_NO = 


0x15, 


DVPACK_ 


_TITLE_S0FT_ID_16 = 


0x16, 


DVPACK_ 


_TITLE_S0FT_ID_17 = 


0x17, 


DVPACK_ 


_TITLE_TEXT_HEADER = 


0x18, 


.DVPACK_ 


_TITLE_TEXT = 


0x19, 


DVPACK^ 


_TITLE_TITLE_START__1A = 


OxlA, 


DVPACK_ 


JITLE_TITLE_START_1B = 


OxlB, 


DVPACK_ 


TITLE_REEL_ID_1C = 


OxlC, 


DVPACK^ 


TITLE_REEL_ID_1D = 


OxlD, 


DVPACK^^ 


JITLE_TITLE_END_1E = 


OxlE, 


DVPACK_ 


TITLE_TITLE_END_1F = 


OxlF, 


DVPACK_ 


CHAPTER__TOTAL_TIME = 


0x20, 


DVPACK_ 


_CHAPTER_REMAIN_TIME = 


0x21, 
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DVPACK_CHAPTER_CHAPTER_NO = 0x22, 

DVPACK_CHAPTER_TIME_CODE = 0x23, 

DVPACK_CHAPTER_BINARY_GROUP = 0x24, 

DVPACK_CHAPTER_RESERVED_25 = 0x25, 

DVPACK_CHAPTER_RESERVED_26 = 0x26, 

DVPACK_CHAPTER_RESERVED_27 = 0x27, 

DVPACK_CHAPTER_TEXT_HEADER = 0x28, 

DVPACK_CHAPTER_TEXT = 0x29, 
DVPACK_CHAPTER_CHAPTER_START_2A = 0x2 A, 
DVPACK_CHAPTER__CHAPTER_START_2B = 0x2B, 

DVPACK_CHAPTER_RESERVED_2C = 0x2 C, 

DVPACK_CHAPTER_RESERVED_2D = 0x2D, 

DVPACK_CHAPTER_CHAPTER_END_2E = 0x2 E, 

DVPACK_CHAPTER_CHAPTER_END_2F = 0x2 F, 

DVPACK_PART_TOTAL_TIME = 0x30, 

DVPACK_PART_REMAIN_TIME = 0x31, 

DVPACK_PART_PART_NO = 0x32, 

DVPACK^PART_TIME_CODE = 0x33, 
DVPACK_PARt_BINARy_GROUP = ' 0x34, 

DVPACK_PART_RESERVED_3 5 ^ = 0x3 5 , 

DVPACK_PART_RESERVED_36 = 0x36, 

DVPACK_PART^RESERVED_37 =. 0x37, 

. DVPACK_PART_TEXT_HEADER = 0x38, 

DVPACK_PART_TEXT = 0x3 9, 

DVPACK_PART_START_3A = 0x3 A, 

DVPACK_PART_START_3B = 0x3 B, 

DVPACK_PART_RESERVED_3C = 0x3 C, 

DVPACK_PART_RESERVED_3D = ' 0x3D, 

DVPACK_PART_PART_END_3E = 0x3 E, 

DVPACK_PART_PART_END_3F = 0x3 F, 

DVPACK_PROGRAM_TOTAL_TIME = 0x40, 

DVPACK_PROGRAM_REMAIN_TIME = 0x41, 

DVPACK_PROGRAM_REC__DTIME = 0x42, 

DVPACK_PROGRAM_TIME__CODE = 0x43, 

DVPACK_PROGRAM___BINARY_GROUP = 0x44, 

DVPACK_PROGRAM_RESERVED_45 = 0x45, 

DVPACK_PROGRAM_RESERVED_46 = 0x46, 

DVPACK_PR0GRAM_RESERVED_47 = 0x47, 

DVPACK_PROGRAM_TEXT_HEADER = 0x48, 

DVPACK_PROGRAM_TEXT = 0x49, 
DVPACK_PR0GRAM_PR0GRAM_START_4A = 0x4 A, 
DVPACK_PR0GRAM_PR0GRAM_START_4B = Ox4B, 

DVPACK_PR0GRAM_RESERVED_4C = 0x4 C, 

DVPACK_PR0GRAM_RESERVED_4D = ' 0x4D, 

DVPACK_PR0GRAM_PR0GRAM_END_4E = 0x4E, 

DVPACK_PR0GRAM_PR0GRAM_END_4F = 0x4 F, 

DVPACK_AAUX_SOURCE = 0x50, 

DVPACK_AAUX_SOURCE_CONTROL = 0x51, 

DVPACK_AAUX_REC_DATE = 0x52, 

DVPACK_AAUX_REC_TIME = 0x53, 
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DVPACK 


_AAUX_BINARY_GROUP = 


0x54, 


DVPACK 


AAUX_CLOSED_CAPTION = 


0x55, 


DVPACK 


_^AAUX_TR = 


0x56, 


DVPACK 


_AAUX_RESERVED_57 = 


0x57, 


DVPACK 


_AAUX_TEXT_HEADER = 


0x58, 


DVPACK_ 


_AAUX_TEXT = 


0x59, 


DVPACK 


_^AAUX_AAUX_START_5A = 


0x5A, 


DVPACK 


_AAUX_AAUX__START_5B = 


0x5B, 


DVPACK 


_AAUX_RESERVED_5C 


0x5C, 


DVPACK_ 


_AAUX_RESERVED_5D = 


0x5D, 


DVPACK 


AAXJX_AAUX_END_5E = 


0x5E, 


DVPACK^ 


AAUX_AAUX_END_5F = 


Ox5F, 


DVPACK_ 


_VAUX_SOURCE = 


0x60, 


DVPACK^ 


_VAUX_SOURCE_CONTROL == 


0x61, 


DVPACK 


_VAUX_REC_DATE = 


0x62, 


DVPACK 


_VAUX_REC_TIME = 


0x63, 


DVPACK_ 


_VAUX_BINARY_GROUP = 


0x64, 


DVPACK 


^VAUX_CLOSED_CAPTION = 


0x65, 


DVPACK_VAUX_TR = 


0x66; 


DVPACK 


VAUX TELETEXT = 


0x67, 


DVPACK^ 


_;VAUX__TEXT_HEADER = 


0x68, 


DVPACK_ 


_VAUX_TEXT = 


0x69, 


DVPACK_ 


_VAUX_VAUX__START_6A = 


Ox6A, 


DVPACK_ 


_VAUX__VAUX_START_6B = 


0x6B, 


DVPACK^ 


_VAUX_^MARINE_MOUNTAIN = 


0x6C, 


DVPACK_ 


VAUX_LONGITUDE_LATITUDE = 


0x6D, 


DVPACK 


TTTVTTV TT7VTTV WMT^ <r "C 

VAUX VAUX END 6 E = 


0x6E, 


DVPACK^^ 


_VAUX_VAUX_END_6F = 


0x6F, 


DVPACK_ 


_CAJyiERA_CONSUiyiER_CAMERA_l = 


0x70, 


DVPACK_ 


_CAMERA_C0NSUMER_CAMERA_2 = 


0x71, 


DVPACK_ 


_CAMERA__RESERVED_72 =: 


0x72, 


DVPACK_ 


_CAMERA_LENS = 


0x73, 


DVPACK_ 


_CAiyiERA_GAIN = 


0x74, 


DVPACK_ 


_CAMERA_PEDESTAL = 


0x75, 


DVPACK_ 


_CAMERA_GAJyny[A = 


0x76, 


DVPACK_ 


_CAMERA_DETAIL = 


0x77, 


DVPACK_ 


_CAMERA_TEXT_HEADER = 


0x78, 


DVPACK_ 


_CAMERA_TEXT = . ' 


0x79, 


DVPACK_ 


_CAMERA_RESERVED_7A = 


Ox7A, 


DVPACK_ 


_CAMERA_CAMERA_PRESET = 


Ox7B, 


DVPACK_ 


_CAMERA_FLARE = 


0x7C, 


DVPACK_ 


_CAMERA_SHADING = 


0x7D, 


DVPACK^ 


_CAMERA_KNEE = 


0x7E, 


DVPACK_ 


_CAMERA_SHUTTER = 


Ox7F, 


DVPACK_ 


_LINE_HEADER = 


0x80, 


DVPACK_ 


LINE_Y = 


0x81, 


DVPACK_ 


_LINE_CR* = 


0x82, 


DVPACK^ 


_LINE_CB = 


0x83, 


DVPACK^ 


LINE_RESERVED_84 = 


0x84, 


DVPACK_^ 


LINE_RESERVED_85 = • . 


0x85, 
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DVPACK_LINE_RESERVED_86 = 0x86, 

DVPACK_LINE_RESERVED_87 = 0x87, 

DVPACK_LINE_TEXT_HEADER = 0x88, 

DVPACK_LINE_TEXT := 0x89, 

DVPACK_LINE_LINE_START_8A = 0x8A, 

DVPACK_LINE_LINE_START_8B = 0x8B, 

DVPACK_LINE_RESERVED_8C = 0x8C, 

DVPACK_LINE_RESERVED_8D = 0x8D, 

DVPACK_LINE_LINE_END_8E = 0x8E, 

DVPACK_LINE_LINE_END_8F = 0x8F, 

DVPACK_MPEG_SOURCE = 0x90, 

DVPACK_MPEG__SOURCE_CONTROL = 0x91, 

DVPACK_MPEG_REC_DATE = 0x92, 

DVPACK_MPEG_REC_TIME = ■ 0x93, 

DVPACK_MPEG_BINARY_GROUP = 0x94, 

DVPACK_MPEG_STREAM = 0x95, 

DVPACK_MPEG_RESERVED_96 = 0x96, 

DVPACK_MPEG_RESERVED_97 = 0x97, 

DyPACK_MPEG_TEXT_HEADER = 0x98, 

DVPACK_MPEG_TEXT = 0x99, 

DVPACK_MPEG_SERVICE_START_9A = 0x9 A, 

DVPACK_MPEG_SERVICE_START_9B = 0x9B, 

DVPACK_MPEG_RESERVED_9C = 0x9C, 

DVPACK_MPEG_RESERVED_9D = 0x9D, 

DVPACK_MPEG_SERVICE_END_9E = 0x9E, 

DVPACK__MPEG_SERVICE_END_9F = . 0x9F, 

DVPACK_RESERyED_RESERVED_AO = OxAO, 

DVPACK_RESERVED__RESERVED_A1 = OxAl, 

DVPACK_RESERVED_RESERVED_A2 = 0xA2 , 

DVPACK_RESERVED_RESERVED_A3 = 0xA3 , 

DVPACK_RESERVED_RESERVED_A4 = 0xA4 , 

DVPACK_RESERVED_RESERVED_A5 = 0xA5 , 

DVPACK_RESERVED_RESERVED_A6 = . 0xA6 , 

DVPACK_^RESERVED_RESERVED_A7 = 0xA7, 

DVPACK_RESERVED_RESERVED_A8 = 0xA8, 

DVPACK_RESERVED_RESERVED_A9 = 0xA9, 

DVPACK_RESERVED_RESERVED_AA = OxAA, 

' DVPACK_RESERVED_RESERVED_AB = OxAB, 

DVPACK_RESERVED_RESERVED_AC = OxAC, 

DVPACK_RESERVED_RESERVED_AD = OxAD, 

DVPACK_RESERVED_RESERVED_AE = OxAE, 

DVPACK_RESERVED_RESERVED_AF = OxAF, 

DVPACK_RESERVED_RESERVED_BO = OxBO, 

DVPACK_RESERVED_RESERVED_B1 = OxBl, 

DVPACK__RESERVED_RESERVED_B2 = OxB2 , 

DVPACK__RESERVED_RESERVED_B3 = 0xB3 , 

DVPACK_RESERVED_RESERVED_B4 = OxB4 , 

DVPACK_RESERVED_RESERVED_B5 = OxB5, 

DVPACK_RESERVED_RESERVED_B6 = 0xB6, 

DVPACK_RESERVED_RESERVED_B7 = 0xB7, 
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DVPACK 


RESERVED 


_RESERVED_ 


,B8 


— 


0xB8, 


DVPACK_ 


_RESERVED_ 


_RESERVED^ 


,B9 


— 


0xB9, 


DVPACK_ 


_RESERVED_ 


_RESERVED_ 


_BA 


= . 


OxBA, 


DVPACK_ 


_RESERVED_ 


_RESERVED_BB 




OxBB, 


DVPACK 


_RESERVED_ 


_Rri btR VBD^ 






OxBC, 


DVPACK_ 


_RESERVED_ 


n T7 C 'C'n T TT^T^ 

KbbCiKVriD 


dD 




OxBD, 


DVPACK_ 


^RESERVED_ 


RbobKVbD 


BE 




OxBE, 


DVPACK_ 


RESERVED^ 


REoER VED 


,BF 




OxBF, 


DVPACK_ 


_RESERVED_ 


RESERVED_ 


,C0 




OxCO, 


DVPACK_ 


RESERVED_ 


RESERVED 


CI 


— 


OxCl, 


DVPACK_ 


_RESERVED_ 


RESERVED 


,C2 




0xC2 , 


DVPACK^ 


_RESERVED_ 


_RESERVED_ 


,C3 




0xC3, 


DVPACK_ 


_RESERVED_ 


_RESERVED_ 


_C4 




0xC4, 


DVPACK_ 


_RESERVED_ 


,RESERVED_ 


,C5 




0xC5, 


DVPACK_ 


RESERVED^ 


_RESERVED^ 


,C6 




0xC6, 


DVPACK_ 


_RESERVED_ 


_RESERVED_ 


,C7 




0xC7, 


DVPACK_ 


_RESERVED_ 


_RESERVED_ 


_C8 




0xC8, 


DVPACK_ 


_RESERVED_ 


_RESERVED_ 


,C9 




0xC9, 


DVPACK_ 


RESERVED^ 


_RESERVED_ 


,CA 




OxCA, 


DVPACK_ 


_RESERVED_ 


RbbrjRVbD 


CB 




OxCB, 


DVPACK_ 


_RESERVED_ 


_RESBRVED_ 


_cc 




OxCC, 


DVPACK_ 


RESERVED^ 


_RESERVED_ 


.CD 




OxCD, 


DVPACK_ 


_RESERVED_ 


^RESERVED 


CE 




OxCE, 


DVPACK^ 


RESERVED_ 


RESERVED 


CF 


— 


OxCF, 


DVPACK^ 


RESERVED^ 


^RESERVED 


DO 




OxDO, 


DVPACK^ 


_RESERVED_ 


_RESBRVBD_ 


_D1 




OxDl, 


DVPACK_ 


_RESERVED_ 


_RE SERVED^ 


_D2 




0xD2 , 


DVPACK_ 


_RESERVED_ 


_RESERVED_ 


_D3 


— 


0xD3, 


DVPACK^ 


RESERVED_ 


^RESERVED_ 


_D4 


— 


0xD4, 


DVPACK^ 


_RESERVED_ 


RESERVED_ 


_D5 


— 


OxD5, 


DVPACK^ 


_RESERVED_ 


RESERVED 


_D6 


— 


0xD6, 


DVPACK_ 


_RESERVED_ 


^RESERVED 


D7 


— 


OxD7, 


DVPACK_ 


_RESERVED_^ 


^RESERVED 


_D8 


— 


0xD8, 


DVPACK_ 


RESERVED^ 


_RESERVED^ 


_D9 




0xD9, 


DVPACK_ 


RESERVED^ 


REbERVED 


DA 




OxDA, 


DVPACK_ 


RESERVED^ 


^REbERVED 


DB 




OxDB, 


DVPACK^ 


RESERVED^ 


T-i y-1 T^nT TL.H \ 

^RESERVED 


DC 




OxDC, 


DVPACK_^ 


RESERVED^ 


^RESERVED_ 


DD 




OxDD, 


DVPACK_ 


_RESERVED_ 


^RESERVED, 


_DE 


— 


OxDE, 


DVPACK_ 


_RESERVED_ 


_RESERVED_ 


DF 


— 


OxDF, 


DVPACK^ 


RESERVED^ 


RESERVED, 


EO 


— 


OxEO, 


DVPACK_ 


_RESERVED_ 


RESERVED, 


_E1 




OxEl, 


DVPACK_ 


_RESERVED_ 


_RESERVED, 


E2 




0xE2, 


DVPACK_ 


_RESERVED_ 


RESERVED, 


E3 




0xE3, 


DVPACK^ 


RESERVED^ 


RESERVED, 


_E4 




OxE4, 


DVPACK^ 


RESERVED_RESERVED_ 


_E5 




0xE5 , 


DVPACK_ 


RESERVED, 


RESERVED_E6 




0xE6, 


DVPACK_ 


RESERVED, 


RESERVED, 


E7 




0xE7, 


DVPACK_ 


RESERVED_ 


_RESERVED_ 


E8 




0xE8, 


DVPACK_ 


RESERVED, 


RESERVED, 


E9 




0xE9, 
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DVPACK_RESERVED_RESERVED_EA = OxEA, 

DVPACK_RESERVED_RESERVED_EB = OxEB, 

DVPACK_RESERVED_RESERVED_EC = OxEC, 

DVPACK_RESERVED_RESERVED_ED = OxED, 

DVPACK_RESERVED_RESERVED_EE = OxEE, 

DVPACK RESERVED RESERVED EF = OxEF, 



DVPACK_ 


^SOFT 


_MODE_ 


_MARKER_ 


_CODE = 


OxFO, 


DVPACK^ 


SOFT 


_^MODE_ 


^OPTION^ 


1 




OxFl, 


DVPACK_ 


_SOFT_ 


_MODE_ 


_OPTION_ 


F2 




OxF2, 


DVPACK_ 


_SOFT_ 


_MODE_ 


_OPTION_ 


_F3 




0xF3, 


DVPACK_ 


_SOFT_ 


_MODE_ 


_OPTION^ 


-r ^ 




0xF4, 


DVPACK_ 


_SOFT_ 


_MODE_ 


OPTION^ 


^F5 




0xF5, 


DVPACK_ 


_SOFT_ 


_MODE_ 


_OPTION^ 


_F6 




0xF6, 


DVPACK_ 


_SOFT_ 


_MODE__ 


OPTION^ 


_F7 




0xF7, 


DVPACK_ 


_SOFT_ 


_MODE^ 


^OPTION^ 


_F8 




0xF8, 


DVPACK_ 


_SOFT_ 


^MODE_ 


^OPTION^ 


_F9 




0xF9, 


DVPACK^ 


_SOFT_ 


MODE_ 


OPTION^ 


FA 




OxFA, 


DVPACK^ 


^SOFT^ 


_MODE_^ 


_OPTION^ 


FB 




OxFB, 


DVPACK^ 


SOFT_ 


.MODE^ 


_OPTION_^ 


_FC 




OxFC, 


DVPACK_ 


_SOFT_ 


^MODE^ 


^OPTION_ 


_FD 




OxFD, 


DVPACK_SOFT_MODE_OPTION^ 


;FE 




■ OxFE, 


DVPACK_ 


_NO_INFO = 








OxPF, 



} DVPACKID; 



typedef struct _DV_METADATA 
{ 

UINT32 cbSize; 
BYTE Pack [5] ; 
} DV_METADATA; 

typedef UINT32 DV__AUDIOBLOCK_ID; 
// May be 0 for DVSL 
// May be 0 - 1 for DVSD, DV25 
// May be 0 - 3 for DV50 
// May be 0 - 7 for DVHl 

typedef struct _DV_AUDIO_METADATA 
{ 

DV_METADATA Metadata; 
DV_AUDIOBLOCK_ID AudioBlock; 
} DV_AUDIO_METADATA; 

// Pack Specific Structures 

typedef struct _DV_METADATA_CONTROL_CASSETTE_ID 
{ 

DV_METADATA DVMetadata; 
// Binary Pack Layout 
// PCO 00000000 
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// PCI AllBBBCC 
// PC2 DDDDEEEE 
// PC3 FFFFFFFF 
// PC4 G G G G H H H H 
// 

//A : ME: Mic Error 

// B : MULTI-BYTES: Maximum number of words to be writtein 
in one cycle of mult i -writing operation 

// C : MEM TYPE: Memory Type 
// D : MEM SIZE of SPACE 0: 

// E : MEM SIZE of the LAST BLANK in SPACEl 

// F : MEM BANK NO. of SPACE 1 

// G : UNITS of TAPE THICKNESS 

// H : 1/10 Of TAPE THICKENSS 

// 

BOOL MicError; 

// 0 : All events in this MIC do not always exist on this 

tape 

// 1 : All events in this MIC certainly exist on this tape 
UINT32 .MultiBytes; 
// 0 : 4 bytes 

// 1 : 8 bytes 

// 2 : 16 bytes 

// 3 - 6 : Reserved 

// 7 : Unlimited 
UINT32 MemoryType; 

// 0 : EEPROM 

// 1 : FeRAM 

// Others = Reserved 
UINT32 MemorySizeOfSpaceO; 
UINT32 MemorySizeOf LastBanklnSpacel ; 

// 0 : 256 bytes 

// 1 : 512 bytes 

// 2 : 1 kbytes 

// 3 : 2 kbytes 

// 4 : 4 kbytes 

// 5 : 8 kbytes 

// 6 : 16 kbytes 

// 7 : 32 kbytes 

// 8 : 64 kbytes 

// Others : reserved 

// OxF : No information 
UINT32 MemoryBankNoOfSpacel; 
UINT32 TapeThickness; 
} DV_METADATA_CONTROL_CASSETTE_ID; 



typedef struct _DV_METADATA_CONTROL_TAPE_LENGTH 
{ 

DV_METADATA DVMetadata; 



UeAHaya,PUC 



37 



Any Docket No. MS1-I708US 



1 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 



// 


Binary Pack Layout 






// 


PCO 


f\ r\ r\ f\ f\ 

0 0 0 0 0 


0 


0 1 


II 


PCI 


A A A A A 


A 


AL 1 


II 


PC2 


A A A A A 


A 


A A 


II 


PC3 


AM A A A A 


A 


A A 


II 


PC4 


11111 


1 


1 1 


II 










II 


A : 


Tape Length, MSB 


is 'at 



left of PC3 (M) , LSB is at 



right of PCI (L) . 

// 

UINT32 TapeLength; 
} DV_METADATA_CONTROL_TAPE_LENGTH; 



typedef struct _DV_METADATA_TEXT_HEADER 
{ 

DV_METADATA DVMetadata; 
// Binary Pack Layout 



HEADER) 



// 


PCO 


0 


0 


0 


0 


1 


0 0 


// 


PCO 


0 


0 


0 1 


1 


0 


0 


0 


// 


PCI 


A 


A 


A A 


A 


A 


A 


AL 


// 


PC2 


B 


B 


B B 


C 


C 


C 


AM 


// 


PCS 


D 


D 


D D 


D 


D 


D 


D 


// 


PC4 


E 


E 


E F 


F 


F 


F 


F 


// 


















// 


A : 


TDP; 


Total 


number 


of t 



(For CONTROL TEXT 



(For TITLE TEXT HEADER) 



part 2) 

// B 
// C 
// D 
// E 

the tape this topic is stored. 

// F : TOPIC TAG 
// 

UINT32 TotalTextData; 
UINT32 Text Type; 



text Data (see Figure 55 of 



TEXT TYPE 

OPN: Option Number 

TEXT CODE: TEXT CODE designates the character set. 
AREA NO. : Area number indicates in which area on 



// 


0 


: Name 




// 


1 


: Memo 




// 


2 


: station 




// 


3 


: Model 




// 


6 


: Operator 




// 


7 


: Subtitle 




// 


8 


: Outline 




// 


9 


: Full Screen 




// 


C 


One byte coded 


font 


// 


D 


Two byte coded 


font 


// 


E 


Graphic 




// 


F 


No Information 




// 


Others : Reserved 





UINT32 OptionNumber; 
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UINT32 Text Code; 

// (See lEC 61834-4 for CONTROL TEXT header pack) 
UINT32 AreaNumber; 
UINT32 TopicTag; 
UINT32 cbTextPacks; 

[size^is (cbTextPacks) ] BYTE pTextPacks [] ; 

// text Pack Layout Each text pack has this layout 
// PCO 00001001 (For CONTROL TEXT) 
// PCO 00011001 (For TITLE TEXT) 
/ / PCI ???????? 
/ / PC2 ???????? 
/ / PC3 ???????? 
/ / PC4 ???????? 

// This pack contains font data, graphic data, or text 

data 

// according to the TEXT TYPE designated in the associated 
TEXT HEADER pack 

} DV_METADATA_TEXT_HEADER; . 

typedef struct _DV_METADATA_TAG 
{ 

DV_METADATA DVMetadata; 
// Binary Pack Layout 

// PCO 00001011 (For CONTROL TAG) 

// PCI AAAAAA ALB 

// PC2 AAAAAAAA 

// PC3 AMAA AAAAA 

// PC4 CDEIFFFF 

// 

// A : Absolute Track Numnber 

// B : Blank Flag 

// C : Text Flag 

// D : Temporary True 

// E : Hold Flag 

// F : Tag ID 
UINT32 AbsoluteTrackNumber; 
BOOL BlankFlag; 

// 1 : Discontinuity exists before this absolute track 

number 

// 0 : Discontinuity does not exist before this absolute 

track number 

BOOL Text Flag; 

// 0 : Text information exists 

// 1 : No text information exists 
BOOL TemporaryTrue ; 

// This flag is only valid for MIC 

// 0 : This event data in MIC is not always valid 

// 1 : This event data in MIC is valid 
BOOL HoldFlag; 
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recording 
recording 



// 0 : Hold the absolute track number after playback or 
// 1 : Renew the absolute trek number after playback or 



number 



track 



PCO 


0 


0 


0 


1 


0 


0 


1 


1 


PCI 


A 


1 


B 


B 


C 


C 


C 


C 


PC2 


1 


D 


D 


D 


E 


E 


E 


E 


PC3 


1 


F 


F 


F 


6 


G 


G 


G 


PC4 


1 


1 


H 


H 


I 


I 


I 


I 



UINT32 Tagid; 
} DV_METADATA_TAG; 

typedef struct _DV_METADATA_TITLE_TIME_CODE 

{ • 

DV_METADATA DVMetadata; 
// Binary Pack Layout 
// 
// 
// 
// 
// 
// 
// 
// 
// 
// 
// 
// 
// 

// H : 
// I : 
BOOL Blank; 
// 0 : 

// 1 : 



A 

B • 

C 

D 

E 

F 

G 



Blank Flag 
Tens of Frames 
Units of Frames 
Tens of Seconds 
Units of Seconds 
Tens of Minutes 
Units of Minutes 
Tens of Hours 
Units of Hours 

Discontinuity exists before the absolute track 

Discontinuity does not exist before the absolute 



UINT32 Frame; 
UINT32 Second; 
UINT32 Minute; 
UINT32 Hour; 
} DV_METADATA_TITLE_TIME_CODE; 



typedef struct _DV_METADATA_AAUX_BINARY_GROUP 
{ 

DV_METADATA DVMetadata; 
DV__AUDIOBLOCK_ID DVAudioBlockId; 
// Binary Pack Layout 

// PCO 00010100 (For TITLE BINARY GROUP) 

// PCI AAAABBBB 

// PC2 CCCCDDDD 

// PC3 EEEEFFFF 

// PC4 G G G G H H H H 

// 

// A : Binary Group 2 
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I 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 



/ / 

II 


B : Binary Group 


1 


II 


C Binary Group 


4 


II 


D : Binary Group 


3 


II 


E : Binary Group 


6 


II 


F : Binary Group 


5 


II 


G : Binary Group 


8 


1 1 


H : Binary Group 


7 


U1NT32 


BinaryGroupl ; 




UINT32 


BinaryGroup2 ; 




UINT32 


BinaryGroup3 ; 




UINT32 


BinaryGroup4 ; 




UINT32 


BinaryGroupS ; 




UINT32 


BinaryGroup6 ; 




UINT32 


BinaryGroup? ; 




UINT32 


BinaryGroupS; 





} DV_METADATA_AAUX_BINARY__GROUP; 



typedef struct _DV_METADATA_BINARY_GROUP 
{ 

DV_METADATA DVMetadata; 
// Binary Pack Layout 

// PCO 00010100 (For TITLE BINARY GROUP) 

// PCI AAAABBBB 

// PC2 CCCCDDDD 

// PC3 EEEEFFFF 

// PC4 G G G G H H H H 

// 

// A : Binary Group 2 - 

// B : Binary Group 1 

// C : Binary Group 4 

// D : Binary Group 3 

// E : Binary Group 6 

// F : Binary Group 5 

// G : Binary Group 8 

// H : Binary Group 7 
UINT32 BinaryGroupl; 
UINT32 BinaryGroup2 ; 
UINT32 BinaryGroupS; 
UINT32 BinaryGroup4 ; 
UINT32 BinaryGroupS; 
UINT32 BinaryGroupS; 
UINT32 BinaryGroup7 ; 
UINT32 BinaryGroupS; 
} DV_METADATA_BINARY_GROUP; 

typedef struct _DV_METADATA_PROGRAM_REC_DTIME 

\ { 

DV_METADATA DVMetadata; 

// Binary Pack Layout 

// PCO 01000010 
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1 

2 
3 
4 
5 
6 
7 
8 
9 
10 
M 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 



II 


PCI 


A A BM B B 


B 


B 


II 


PC2 


CM C CL DM D 


D 


D 


II 


PC 3 


EM E E FM F 


F 


F 


II 


PC4 


E E E EL GM 


G 


G 


II 










II 


A : 


Recording Mode 






II 


B : 


Minutes 






II 


C : 


Week 






II 


D : 


Hours 






II 


E : 


Year 






II 


F : 


Day 






II 


G : 


Month 






UINT32 


RecordingMode ; 






II 


0 : 


Video 






II 


1 : 


Audio 






II 


2 : 


Audio Video 






II 


3 : 


Duplicate 






UINT32 


Minutes; 






II 


3F 


No information 




UINT32 


Hours ; 






II 


IF 


No information 




UINT32 


Day; 






UINT32 


Month; 






UINT32 


Year; 






II 


Last two digits of 


Year 


UINT32 


WeekDay; 






II 


0 : 


Sunday 






II 


1 : 


Monday 






II 


2 : 


Tuesday 






II 


3 : 


Wednsday 






II 


4 : 


Thursday 






II 


5 : 


Friday 






II 


6 : 


Saturday 






II 


7 : 


No Information 







} DV_METADATA_PROGRAM_REC_DTIME; 

typedef struct _DV__METADATA_AAUX_SOURCE 
{ 

DV_METADATA DVMetadata; 
DV_AUDIOBLOCK_ID DVAudioBlockId; 

// Binary Pack Layout 

// PCD 01010000 

// PCI AlBBBBBB 

// PC2 CDDEFFFF 

// PC3 1 G H I I I I I 

// PC4 JKLLLMMM 
// 

// A : Locked Flag 

// B : Audio Frame Size 
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// 


c 


: Stereo Mode 


// 


D 


\ Audio Channels per audio block 


// 


E 


: Pair Bit 


II 


F 


Audio Mode 


II 


G 


: Multi -Language Flag 


II 


H 


50/60 


II 


I 


System Type 


II 


J 


Emphasis Flag 


II 


K 


Time Constatn of Emphasis 


II 


L 


Sampling Frequency 


II 


M 


Quantization 



BOOL LockedFlag; 

// 0 : Locked Mode 

// 1 : Unlocked Mode 
UINT32 AudioFrameSize; 
BOOL StereoMode; 

// 0 : Multi -Stereo audio 

// 1 : Lumped Audio 
UINT32 Channel; 

// 0 : One channel per audio block 

// 1 : Two channels per audio block 

// Others : Reserved 
BOOL PairBit; 

// 0 : One pair of channels 

// 1 : Independent channel 
UINT32 AudioMode; 

// The interpretation of auido mode depends on the Stereo 

Mode , 

// the channel, and the audio block in question. See 

section 

// 8.1 of lEC 61834-4. 
BOOL MultiLanguage; 

// 0 : Recorded in Multi -Language 

// 1 : Not recorded in Multi -Language 
BOOL Fi fty Sixty ; 

// 0 : 60 Field System (NTSC) 

// 1 : 50 Field System (PAL) 
UINT32 SystemType; 

// Defines system type of video signal in combination with 

50/60 flag 

// See section 8.1 of lEC 61834-4 
BOOL Emphasis; 

// 0 : Emphasis on 

// 1 : Emphasis off 
BOOL TimeConstant ; 

// 1 : 50.15 micro-seconds 

// 0 : Reserved 
UINT32 SamplingFrequency; 
UINT32 Quantization; 
} DV_METADATA_AAUX_SOURCE; 
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typedef struct _DV_METADATA_AAUX_SOURCE_CONTROL 
{ 

DV_METADATA DVMetadata; 
DV_AXJDIOBLOCK_ID DVAudioBlockId; 



II 


Binary Pack Layout 




II 


PCO 


01010001 




II 


PCI 


AABBCCDD 




II 


PC2 


EFGGGHHH 




II 


PC3 


IJJJJJJJ 




II 


PC4 


IKKKKKKK 




II 








II 


A : 


Copy Gneration Management System 


II 


B : 


Input Source of 


Just Previous Recording 


II 


C : 


Number of times 


Compressed 


II 


D : 


Source Situation 




II 


E : 


Record Start 




II 


F : 


Record End 




II 


G : 


Record Mode 




II 


H : 


Insert Channel 




II 


I : 


Direction Flag 




II 


J : 


Speed . 




II 


K : 


Genre Category 




UINT32 


CopyGenerationManagementSystem; ^ 


II 


P : 


Copying permitted without restriction 


II 


1 : 


Not Used 




II 


2 : 


One generation of copies permitted 


II 


3 : 


No Copying Permitted 


UINT32 


InputSource ; 




II 


0 : 


Analog input 




II 


1 : 


Digital input 




II 


2 : 


Reserved 




II 


3 : 


No Information 




UINT32 


Compression; 




// 


0 : 


Compressed once 




// 


1 : 


Compressed twice 




// 


2 : 


Compressed three 


times or more 


// 


3 : 


No Information 




UINT32 


SourceSituation; 




// 


0 : 


Scrambled source 


with audience restrictions 


// 


1 : 


Scrambled source 


wihout audience restrictions 


// 


2 : 


Source with audience restrictions or descrambled 



source with audience restrictions 

// 3 : No Information 

BOOL RecordingStart ; 

// 0 : Recording start point 

// 1 : Not recording start point 

BOOL RecordingEnd; 

// 0 : Recording end point 
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// 1 : Not recording end point 
UINT32 RecordMode; 
// 1 : Original 

// 3 : One channel inserted (CHI or CH2 or CH3 or CH4) 

// 4 : Four channels inserted (CHI and CH2 and CH2 and 

CH4) 

// 5 : Two channels inserted (CHI and CH2) or (CH3 and 

CH4) 

// 7 : Invalid Recording (MUTE) 
UINT32 InsertChannel; 
// 0 : CHI 
// 1 : CH2 
// 2 : CH3 
// 3 : CH4 
// 4 : CHI and CH2 
// 5 : CH3 and CH4 

// 6 : CHI and CH2 and CH3 and CH4 

// 7 : No Information 
BOOL Direct ionFlag; 

// 0 : Reverse Direction 

// 1 : Forward Direction 
UINT32 PlaybackSpeed; 

// See lEC 61834-4 , Section 8.2 
UINT32 GenreCategory; 

// See lEC 61834-4 Section 3.3 
} DV_METADATA__AAUX_SOURCE_CONTROL; 

typedef struct _DV_METADATA_AAUX_REC_DATE 

{ 

DV_METADATA DVMetadata; 
DV_AUDIOBLOCK_ID DVAudioBlockId; 
// Binary Pack Layout 

// PCO 01010010 (For AAUX REC DATE) 

// PCI ABCCDDDD 

// PC2 llEEFFFF 

// PC3 GGGHIIII 

// PC4 JJJJKKKK 

// 

// A : Daylight Savings 
// fi : Thirty Minutes 
// C : Tens of Time Zone 
// D : Units of Time Zone 
// E : Tens of Day 
// F : Units of Day 
// G : Week 
// H : Tens of Month 
// I : Units of Month 
// J : Tens of Year 
// K : Units of Year 
BOOL DaylightSavingsTime; 
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// 0 : Daylight Savings Time 

// 1 : Normal 
BOOL ThirtyMinutesFlag; 

// 0 : 30 Minutes 

// 1 : 00 Minutes 
UINT32 TimeZone; 
UINT32 Day; 
UINT32 Week; 
UINT32 Month; 

UINT32 LastTwoDigitsOfYear; 
} DV_METADATA_AAUX_REC_DATE; 

typedef struct _DV_METADATA_VAUX_REC_DATE 
{ 

DV_METADATA DVMetadata; 

// Binary Pack Layout 

// PCO 01100010 (FOR VAUX REC DATE) 
// PCI ABCCDDDD 
// PC2 llEEFF. FF 
// PC3 G G G H I I I I 
//. PC4 J J J J K K K K 

// . 

// A : Daylight Savings 

// B : Thirty Minutes 

// C : Tens of Time Zone 

// D : Units of Time Zone 

// E : Tens of Day 

// F : Units of Day 

// G : Week 

// H : Tens of Month 

// I : Units of Month 

// J : Tens of Year 

// K : Units of Year 
BOOL DaylightSavingsTime; 

// 0 : Daylight Savings Time 

// 1 : Normal 
BOOL ThirtyMinutesFlag; 

// 0 : 30 Minutes 

// 1 : 00 Minutes 
UINT32 TimeZone; 
UINT32 Day; 
UINT32 Week; 
UINT32 Month; 

UINT32 LastTwoDigitsOfYear; 
} DV_METADATA_VAUX_REC_DATE; 

typedef struct _DV_METADATA_AAUX_REC_TIME 
{ 

DV_METADATA DVMetadata; 
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DV_AUDIOBLOCK_ID DVAudioBlockId; 
// Binary Pack Layout 

// PCO 01010011 (For AAUX REC TIME) 

// PCI 1 lAABBBB 

// PC2 ICCCDDDD 

// PC3 lEEEFFFF 

// PC4 IIGGHHHH 

// 

// A : Tens of Frames 

// B : Units of Frames 

lie : Tens of Seconds 

// D : Units of Seconds 

II E : Tens of Minutes 

// F : Unites of Minutes 

II G z Tens of Hours 

II H : Units of Hours 
UINT32 Frame; 
UINT32 Second; 
UINT32 Minute; 
UINT32 Hour; 
} DV_METADATA_AAUX_REC_TIME; 

typedef struct _DV_METADATA_VAUX_REC_TIME 
{ 

DV_METADATA DVMetadata; 

// Binary Pack Layout 

// PCO 01100011 (For VAUX REC TIME) 

// PCI llAABBBB 

// PC2 ICCCDDDD 

// PC3 lEEEFFFF 

// PC4 IIGGHHHH 

// 

// A : Tens of Frames 

// B : Units of Frames 

// C : Tens of Seconds 

// D : Units of Seconds 

// E : Tens of Minutes 

// F : Unites of Minutes 

II G : Tens of Hours 

II K : Units of Hours 
UINT32 Frame; 
UINT32 Second; 
UINT32 Minute; 
UINT32 Hour; 
} DV_METADATA_VAUX_REC_TIME; 

typedef struct _DV_METADATA_AAUX_CLOSED_CAPTION 
{ 
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DV_METADATA DVMetadata; 
DV_AUDIOBLOCK_ID DVAudioBlockId; 

// Binary Pack Layout 

// PCO 01010101 (For AAUX CLOSED CAPTION) 
// PCI 1 lAAABBB 
// PC2 IICCCDDD 
.// PC3 1 1 1 1 1 1 1 1 
// PC4 11111111 
// 

// A : Main Audio Language 

// B : Main Audio Type 

// C : Second Audio Language 

// D : Second Audio Type 
UINT32 MainAudioLanguage ; 

// 0 : Unknown 

// 1 : English 

1 1 2 : Spanish 

// 3 : French 

// 4 : German 

// 5 : Italian 

// 6 : Others 

// 7 : None 
UINT32 MainAudioType ; 

// 0 : Unknown 

// 1 : Mono 

// 2 : Simulated stereo 

// 3 : True Stereo 

// 4 : Stereo surround 

// 5 : Data Srevice 

// 6 : Others ^ 

// 7 : None 
UINT3 2 SecondAudioLanguage ; 

// 0 : Unknown 

// 1 : English 

// 2 : Spanish 

// 3 : French 

// 4 : German 

// 5 : Italian 

// 6 : Others 

// 7 : None 
UINT32 SecondAudioType; 

// 0 : Unknown 

// 1 ; Mono 

// 2 : Descriptive video service 

// 3 : Non- Program audio 

// 4 : Special Effects 

// 5 : Data Srevice 

// 6 : Others 

// 7 : None 
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} DV_METADATA_AAUX_CLOSED_CAPTION; 



typedef struct _DV_METADATA_AAUX_TR 



{ 



DV_METADATA DVMetadata; 

DV AUDIOBLOCK ID DVAudioBlockId; 



// 


Binary Pack Layout 








// 


PCO 0 10 10 


1 


1 


0 


// 


PCI A A A AL B 


B 


B 


B 


// 


PC2 A A A A A 


A 


A 


A 


// 


PC3 A A A A A 


A 


A 


A 


// 


PC4 AM A A A A 


A 


A 


A 



// 

// A : Data 

// B : Data type 
UINT32 DataType; 
UINT32 Data; 
} DV_METADATA__AAUX_TR; 

typedef struct -_DV_METADATA_VAUX_TR 
{ 

DV METADATA DVMetadata; 



// 


Binary Pack Layout 








// 


PCO 0 110 0 


1 


1 


1 


// 


PCI A A A AL B 


B 


B 


B 


// 


PC2 A A A A A 


A 


A 


A 


// 


PCS A A A A A 


A 


A 


A 


// 


PC4 AM A A A A 


A 


A 


A 



// 

// A : Data 

// B : Data type 

UINT32 DataType; 

UINT32 Data; 
} DV_METADATA_VAUX_TR; 



(For AAUX TR) 



(For VAUX TR) 



typedef struct _DV_METADATA_VAUX_SOURCE 
{ 

DV_METADATA DVMetadata; 
// Binary Pack Layout 
// PCO 01100000 
// PCI AAAABBBB 

CDEEFFFF- 
GGHIIIII 
JJJJJJJJ 



// PC2 
// PC3 
// PC4 
// 

// A 
// B 
// c 



Tens of TV Channel 
Units of TV Channel 
B/W 
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3 
4 
5 
6 
7 
8 
9 
10 
II 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 



// 


D 


> Enable Color 


// 


E 


Color frames identification 


// 


F 


Hundreds of TV Channel 


// 


G 


Source code 


// 


H 


50/60 


// 


I 


Signal Type 


// 


J 


Tuner Category 



UINT32 Channel; 

BOOL BlackAndWhiteFlag; 

// 0 : Black and White 

// 1 : Color 
BOOL ColorFramesEnableFlag; 

// 0 : CLF is valid 

// 1 : CLF is invalid 
UINT32 ColorFramesId; 

// For 525-60 

// 0 : Color Frame A 

//I : Color Frame B 

// 

// For 625-50 
. // 0 : 1st, 2nd Field 

// 1 : 3rd, 4th Field 

// 2 : 5th, 6th Field 

// 3 : 7th, 8th Field 
UINT32 SourceCode; 
BOOL FiftySixty; 

// 0 : 60 Field System (NTSC) 

// 1 : 50 Field System (PAL) 
UINT32 SType; 
UINT32 TunerCategory; 
} DV_METADATA_VAUX_SOURCE; 

typedef struct _DV_METADATA_VAUX_SOURCE_CONTROL 
{ 

DV_METADATA DVMetadata; 



// 


Binary Pack Layout 


// 


PCO 


01100001 


// 


PCI 


AABBCCDD 


// 


PC2 


EIFFIGGG 


// 


PC3 


HIJKLMNN 


// 


PC4 


10000000 


// 






// 


A : 


Copy Generation Management System 


// 


B : 


Input source of just previous recording 


// 


C : 


The number of times of compression 


// 


D : 


Source and recorded situation 


// 


E : 


Recording start point 


// 


F : 


Record Mode 


// 


G : 


Display Select Mode 


// 


H .: 


Frame/Field Flag 
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/ / 

11 


I : First/Second Flag 


1 / 

II 


J : Frame Change Flag 


/ / 


j\ : xnceriace riag 


/ / 


u : buj. JL JL -r lexu pxcuure riag 


/ / 


M still Camera Picture Flag 


II 


N : Broadcast System 


II 


0 : Genre Category 


U XrJ i J z 


CopyGenera t lonManagement Sys t em ; 


/ / 


0 : Copying permitted without restriction 


II 


1 : Not usea 


II 


2 : One generation of copying permitted 


II 


3 : No copying permitted 


UINT3 2 


Just Previous Input ; 


II 


0 : Analog 


II 


1 : Digital 


II 


2 : Reserved 


II 


3 : No Information 


UINT32 


Compression; 


II 


0 : Compresssion once 


// 


1 : Compression twice 


II 


2 : Compression three times or more 


II 


3 : No. Information 


UINT32 


Sources i tuat ion ; 


II 


0 : Scrambled source with audience restrictions 


recorded without 


descrambling 


II 


1 : Scrambled source without audience restrictions 



recoreded wihtout descrambling 

II 2 Source with audience restrictions or descrambled 
source with audience restrictions 

// 3 : No Information 
BOOL RecordStart; 

// 0 : Recording start point 

III : Not recording start point 
UINT32 RecordMode; 

// 0 : Original 
111: Reserved 
II 2 : Insert 

II 3 : Invalid Recording • 
UINT32 DisplaySelect; 

BOOL FrameField; » 

// 0 : only one of two fields is output twice 

// 1 : both fields are output in order 
BOOL FirstSecond; 

// 0 : Field 2 is output 

111: Field 2 is output 
BOOL FrameChange; 

// 0 : Same Picture as the immediate previous frame 

// 1 : Different Picture from the immediate previous 

frame 

BOOL Interlace; 
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// 0 : Non-interlaced 
// 1 : Interlaced or unrecognized 
BOOL StillField; 

// 0 : The time difference between the fields is 
approximately Os 

// 1 : The time difference between the fiels is 
approximately 1.001/60 s or 
// 1/50 s 

BOOL StillCamera; 

// 0 : Still camera picture 
// 1 : Not Still Camera Picture 
UINT32 BroadcastSystem; 
UINT32 GenreCategory; 
} DV_METADATA_VAUX_SOURCE_CONTROL; 

typedef struct _DV_METADATA_VAUX_CLOSED_CAPTION 
{ 

DV_METADATA DVMetadata; 
// Binary Pack Layout 

// PCO 0 1 1 0 0 1.0 1 (For VAUX CLOSED CAPTION) 

// PCI A AAAAAAA 

// PC2 BBBBBBBB 

// PC3 CCCCCCCC 

// PC4 DDDDDDDD 

// 

// A : 1st FIELD Line 21 1st BYTE 

// B : 1st FIELD Line 21 2nd BYTE 
7/ C : 2nd FIELD Line 21 1st BYTE 
// D : 2nd FILED Line 21 2nd BYTE 

UINT32 FirstFieldFirstByte; 
UINT32 FirstFieldSecondByte; 
UINT32 SecondFieldFirstByte; 
UINT32 SecondFieldSecondByte; 
} DV_METADATA_VAUX_CLOSED_CAPTION; 



typedef struct _DV_METADATA_CAMERA_C0NSUMER_CAMERA_1 

{ - 

DV_METADATA DVMetadata; 

// Binary Pack Layout 

// PCO 01110000 

// PCI llAAAAAA 

// PC2 BBBBBCCC 

// PC3 DDDEEEEE 

// PC4 FGGGGGGG 
// 

// A : Iris 

// B : Automatic Exposure Mode 
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/ / 

II 


C : 


Automatic Gain Control 


II 


D : 


White Balance Mode 


II 


E : 


White Balance 


II 


F : 


Focus Mode 


II 


G : 


Focus 


UINT32 


Iris; 


II 


Position in terms of F number 


II 


0 - 


60 : IP where iris position = 2 (IP / 8 


t / 
II 


61 


: Under Fl.O 


II 


62 


: Close 


II 


63 


: No Information 


UINT32 


AEMode ; 


II 


0 : 


Full Automatic 


II 


1 : 


Gain priority mode 


II 


2 : 


Shutter priority mode 


II 


3 : 


Iris priority mode 


II 


4 : 


Manual 


II 


15 


: No Information 


II 


Others Reserved 


UINT32 


AGC 


) ► 


// 


0 - 


13 : G 


II 


15 


: No Information 


UINT32 


WBMode ; 


// 


0 : 


Automatic 


II 


1 : 


Hold 


II 


2 : 


one -push 


II 


3 : 


preset 


II 


7 : 


No Information . - 


II 


Others : Reserved 


UINT3 2 


WhiteBalance ; 


II 


0 : 


Candle 


II 


1 : 


Incandescent lamp 


II 


2 : 


Florescent lamp of low color temperature 


II 


3 : 


Flourescent lamp of high color tempertaure 


II 


4 : 


Sunlight 


II 


5 : 


Cloudiness 


II 


6 : 


Others 


II 


31 


: No Information 


II 


Others : Reserved 


BOOL FocusMode; 


// 


0 : 


Automatic Focus 


// 


1 : 


Manual Focus 



UINT32 FocusPosition; 

// 0 - 126 : Focus Postion = M x 10 ^ L 
// where M is most significant 5 bits of focus 

// and L is least significant 2 bits of focus 

// 127 : No Information 
} DV_METADATA_CAMERA_C0NSUMER_CAMERA_1; 

typedef struct _DV_METADATA_CAMERA_C0NSUMER_CAMERA_2 
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I 

2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
24 
25 



{ 

DV METADATA DVMetadata ; 





Binary Pack Layout 


// 


PCO 


01110001 


// 


PCI 


1 lABBBBB 


// 


PC2 


T\ Tn TTi TT' IT' TT^ T7 

CDEEEEEE 


// 


PC3 


1~l 'O T~1 T*^ I 

FFFFFFFF 


// 


PC4 


^ T T T T T T T T T T 

GHHHlllI 


II 






II 


A : 


Vertical Panning Direction 


II 


B : 


Vertical Panning Speed 


II 


C : 


Image Stabilizer 


II 


D : 


Horizontal Panning Direction 


II 


E : 


Horizontal Panning Speed 


II 


F : 


Focal Length 


II 


G : 


Zoom Enable Flag 


II 


H : 


Units of E-Zoom 


II 


I : 


1/10 of E-Zoom 



BOOL VerticalPanningDirection; 

// 0 : Same direction as the vertical scanning 
.// 1 : Opposite direction as the vertical scanning 

UINT32 VerticalPanningSpeed; 
// 0 - 29 : Panning Speed 
// 30 : More than 29 lines per field 
// 31 : No Information 

BOOL ImageStabilizer; 
// 0 : On 

// 1 : Off ' . ■ 

BOOL HorizontalPanni ngD i r e c t i on ; 

II 0 X Same direction as horizontal scanning 

// 1 : Opposite direction as horizontal scanning 
UINT32 HorizontalPanningSpeed; 

// 0 - 30 : Panning Speed 

// 62 : More than 122 pixels per field 

// 63 : No Information 
UINT32 FocalLength; 

// 0 - 254 : Focal Length 

// 255 : No Informtion 
BOOL ZoomEnable; 

1 1 0 : Electronic Zoom ON 

// 1 : Electronic Zoom Off 
UINT32 ElectricZoom; 

II 0 - IS : 0.0-7. 9 units of electric zoom 

// 126 : More than 8 times 

// 127 : No Information 
} DV_METADATA_CAMERA_C0NSUMER_CAMERA_2 ; 

typedef struct _DV_METADATA_CAMERA_SHUTTER 
{ 

DV_METADATA DVMetadata; 
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2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
IS 
19 
20 
21 
22 
23 
24 
25 



II 


Binary Pack Layout 






II 














II 


For 


Consumer Use 








II 














II 


PCO 


0 


1111 


1 


1 


1 


II 


PCI 


1 


1111 


1 


1 


1 


II 




1 


1111 


1 


1 


1 


jj 1 

II 


PC 3 


A 


A A A A 


A 


A 


AL 


II 


PC4 


1 


AM A A A 


A 


A 


A 


II 














II 


For 


Professional Use 






II 














II 


PCO 


0 


1111 


1 


1 


1 


II 


PCI 


B 


B B B B 


B 


B 


B 


II 


PC2 


C 


C C C C 


C 


C 


C 


II 


PC3 


1 


1111 


1 


1 


1 


II 


PC4 


1' 


1111 


1 


1 


1 


II 














II 














II 


A : 


Shutter Speed 








II 


B : 


Upper Line Shutter Speed 


II 


C : 


Lower Line Shutter Speeed 


II 














UINT3 2 


ShutterSpeed; 








II 


0x0000 


- 0x7 FFE : 


Shutter Speed 


II 


0x7FFF 


: No Information 




UINT32 


UpperLineSpeed ; 








// 


0 - 


254 


: Shutter 


Speed 




// 


255 


: No Information 






UINT32 


LowerLineSpeed; 









} DV_METADATA_CAMERA_SHUTTER; 



CoDclttsion 

Although the invention has been described in language specific to structural 
features and/or methodological acts, it is to be understood that the invention 
defined in the appended claims is not necessarily limited to the specific features or 
acts described. Rather, the specific features and acts are disclosed as exemplary 
forms of implementing the claimed invention. 
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